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Abstract 

While  the  need  for  data  and  message  confidentiality  is  well  known,  the  need  to 
protect  against  traffic  analysis  on  networks,  including  unclassified  networks,  is  less 
widely  recognized.  Tor  is  a  circuit-based  low-latency  anonymous  communication 
service  that  resists  traffic  analysis.  This  second-generation  Onion  Routing  system 
adds  to  the  first-generation  design  with  perfect  forward  secrecy,  congestion  control, 
directory  servers,  integrity  checking,  variable  exit  policies,  and  a  practical  design 
for  rendezvous  points.  Tor  works  on  the  real-world  Internet,  requires  no  special 
privileges  or  kernel  modifications,  requires  little  synchronization  or  coordination 
between  nodes,  and  provides  a  reasonable  tradeoff  between  anonymity,  usability, 
and  efficiency. 


1  Introduction 

It  is  well  known  that  encryption  hides  the  content  of  communication  but  does  nothing 
to  hide  who  is  communicating  with  whom.  Indeed,  Whit  Diffie,  an  inventor  of  public- 
key  cryptography,  has  noted  that  traffic  analysis,  not  cryptanalysis,  is  the  backbone 
of  signals  intelligence  [9].  The  military  has  many  reasons  to  communicate  over  open 
networks  without  revealing  its  communications  partners.  Communicating  in  this  way 
assists  intelligence  gathering  from  open  Internet  sources,  rapid  formation  of  dynamic 
coalitions  without  an  existing  shared  private  infrastructure  between  members,  and  pri¬ 
vate  communication  with  vendors  to  help  conceal  procurement  patterns.  Finally,  it  is 
sometimes  not  the  communicants  that  are  sensitive  but  their  location:  a  server  whose 
physical  or  logical  location  is  known  may  be  vulnerable  to  physical  attack  and  denial 
of  service. 


*  This  work  supported  by  DARPA  and  ONR. 
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Onion  Routing  is  an  overlay  network  concept  for  making  anonymous  connections 
resistant  to  eavesdropping  and  traffic  analysis.  It  permits  low-latency  TCP-based  com¬ 
munication  such  as  web  traffic,  secure  shell  remote  login,  and  instant  messaging.  The 
current  design  and  implementation,  Tor,  improves  on  the  original  [13,  16,  18,  19]  by 
providing  perfect  forward  secrecy  (see  Section  2),  interfacing  to  unmodified  appli¬ 
cations  via  SOCKS,  multiplexing  application  connections  on  Onion  Routing  circuits, 
adding  congestion  control  adding  integrity  checking,  and  including  a  rendezvous  points 
design  that  protects  the  responder  of  a  connection  in  addition  to  the  initiator. 

Onion  Routing  may  be  used  anywhere  traffic  analysis  is  a  concern.  Because  Onion 
Routing  is  an  overlay  network,  it  can  exist  on  top  of  public  networks  such  as  the  In¬ 
ternet  without  any  modification  to  the  underlying  routing  structure  or  protocols.  In 
addition  to  protecting  data  confidentiality  and  integrity,  the  Onion  Routing  protocol 
hides  the  endpoint  of  each  transmission.  An  intelligence  analyst  surfing  a  web  site 
through  Onion  Routing  is  hidden  both  from  that  web  site  and  from  the  Onion  Routing 
network  itself.  On  the  other  hand,  Onion  Routing  separates  anonymity  of  the  commu¬ 
nication  from  that  of  the  data  stream.  That  is,  a  procurement  officer  can  place  orders 
with  a  vendor  and  completely  authenticate  himself  to  the  vendor  while  still  hiding  the 
communication  from  any  observers — including  compromised  Onion  Routing  network 
components.  Onion  Routing  can  also  be  used  to  provide  location  hidden  servers  with 
better  protection  and  yet  less  redundancy  than  standard  approaches  to  distributed  denial 
of  service.  In  this  paper  we  provide  a  brief  overview  of  the  Tor  design.  More  detailed 
description  is  given  in  [10].  As  we  describe  the  system  design,  we  will  note  how  Onion 
Routing  can  be  used  to  protect  military  communications  in  the  above  described  set¬ 
tings. 

1.1  Related  Work 

We  give  here  a  broad  description  of  prior  work;  for  a  more  complete  list  of  references 
and  comparisons,  see  [10]. 

Modern  anonymity  systems  date  to  Chaum’s  Mix-Net  design  [5].  Chaum  proposed 
hiding  the  correspondence  between  sender  and  recipient  by  wrapping  messages  in  lay¬ 
ers  of  public-key  cryptography,  and  relaying  them  through  a  path  composed  of  “mixes.” 
Each  mix  in  turn  decrypts,  delays,  and  re-orders  messages,  before  relaying  them  toward 
their  destinations. 

Subsequent  relay-based  anonymity  designs  have  diverged  in  two  main  directions. 
Some  have  tried  to  maximize  anonymity  at  the  cost  of  introducing  comparatively  large 
and  variable  latencies.  Because  of  this  decision,  these  high-latency  networks  resist 
strong  global  adversaries,  but  introduce  too  much  lag  for  interactive  tasks  like  web 
browsing,  Internet  chat,  or  SSH  connections. 

Tor  belongs  to  the  second  category:  low-latency  designs  that  try  to  anonymize 
interactive  network  traffic.  These  systems  handle  a  variety  of  bidirectional  protocols. 
They  also  provide  more  convenient  mail  delivery  than  the  high-latency  anonymous 
email  networks,  because  the  remote  mail  server  provides  explicit  and  timely  delivery 
confirmation.  But  because  these  designs  typically  involve  many  packets  that  must  be 
delivered  quickly,  it  is  difficult  for  them  to  prevent  an  attacker  who  can  eavesdrop  both 
ends  of  the  communication  from  correlating  the  timing  and  volume  of  traffic  entering 
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the  anonymity  network  with  traffic  leaving  it.  These  protocols  are  also  vulnerable  to 
active  attacks  in  which  an  adversary  introduces  timing  patterns  into  traffic  entering  the 
network  and  looks  for  correlated  patterns  among  exiting  traffic.  Although  some  work 
has  been  done  to  frustrate  these  attacks,  most  designs  protect  primarily  against  traffic 
analysis  rather  than  traffic  confirmation  (cf.  Section  2.1). 

The  simplest  low-latency  designs  are  single-hop  proxies  such  as  the  Anonymizer 
[2],  wherein  a  single  trusted  server  strips  the  data’s  origin  before  relaying  it.  More 
complex  are  distributed-trust,  circuit-based  anonymizing  systems.  In  these  designs,  a 
user  establishes  one  or  more  medium-term  bidirectional  end-to-end  circuits,  and  tun¬ 
nels  data  in  fixed-size  cells.  Establishing  circuits  is  computationally  expensive  and 
typically  requires  public-key  cryptography,  whereas  relaying  cells  is  comparatively  in¬ 
expensive  and  typically  requires  only  symmetric  encryption.  Because  a  circuit  crosses 
several  servers,  and  each  server  only  knows  the  adjacent  servers  in  the  circuit,  no  single 
server  can  link  a  user  to  her  communication  partners. 

There  are  many  other  circuit-based  designs,  that  make  a  variety  of  design  choices; 
we  again  refer  the  reader  to  [10]  for  more  information. 

2  Design  goals  and  assumptions 

Goals 

Like  other  low-latency  anonymity  designs.  Tor  seeks  to  frustrate  attackers  from  linking 
communication  partners,  or  from  linking  multiple  communications  to  or  from  a  sin¬ 
gle  user.  Within  this  main  goal,  however,  several  considerations  have  directed  Tor’s 
evolution. 

Diversity:  If  all  onion  routers  were  operated  by  the  defense  department  or  ministry 
of  a  single  nation  and  all  users  of  the  network  were  DoD  users,  then  traffic  patterns  of 
individuals,  enclaves,  and  commands  can  be  protected  from  hostile  observers,  whether 
external  or  internal.  However,  any  traffic  emerging  from  the  Onion  Routing  network 
to  the  Internet  would  still  be  recognized  as  coming  from  the  DoD,  since  the  network 
would  only  carry  DoD  traffic.  Therefore,  it  is  necessary  that  the  Onion  Routing  network 
carry  traffic  of  a  broader  class  of  users.  Similarly,  having  onion  routers  run  by  diverse 
entities,  including  nonmilitary  entities  and  entities  from  different  countries,  will  help 
broaden  and  enlarge  the  class  of  users  who  will  trust  that  system  insiders  will  not 
monitor  their  traffic.  This  will  provide  both  a  greater  diversity  and  greater  volume  of 
cover  traffic.  Unlike  confidentiality,  a  single  entity  cannot  achieve  anonymity  without 
collaboration,  no  matter  how  strong  the  technology. 

Deployability:  The  design  must  be  deployed  and  used  in  the  real  world.  Thus  it 
must  not  be  expensive  to  run  (for  example,  by  requiring  more  bandwidth  than  onion 
router  operators  are  willing  to  provide);  must  not  place  a  heavy  liability  burden  on 
operators  (for  example,  by  allowing  attackers  to  implicate  onion  routers  in  illegal  ac¬ 
tivities);  and  must  not  be  difficult  or  expensive  to  implement  (for  example,  by  requir¬ 
ing  kernel  patches,  or  separate  proxies  for  every  protocol).  We  also  cannot  require 
non-anonymous  parties  (such  as  websites)  to  run  our  software. 

Usability:  A  hard-to-use  system  has  fewer  users — and  because  anonymity  systems 
hide  users  among  users,  a  system  with  fewer  users  provides  less  anonymity.  Usability 
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is  thus  not  only  a  convenience:  it  is  a  security  requirement  [1,  3].  Tor  should  therefore 
not  require  modifying  applications;  should  not  introduce  prohibitive  delays;  and  should 
require  users  to  make  as  few  configuration  decisions  as  possible.  Finally,  Tor  should  be 
easily  implemented  on  all  common  platforms;  we  cannot  require  users  to  change  their 
operating  system  in  order  to  be  anonymous.  (The  current  Tor  implementation  runs  on 
Windows  and  assorted  Unix  clones  including  Linux,  FreeBSD,  and  MacOS  X.) 

Flexibility:  The  protocol  must  be  flexible  and  well-specified,  so  Tor  can  serve  as 
a  test-bed  for  future  research.  Many  of  the  open  problems  in  low-latency  anonymity 
networks,  such  as  generating  dummy  traffic  or  preventing  Sybil  attacks  (where  one  en¬ 
tity  masquerades  as  many)  [11],  may  be  solvable  independently  from  the  issues  solved 
by  Tor.  Hopefully  future  systems  will  not  need  to  reinvent  Tor’s  design.  (But  note  that 
while  a  flexible  design  benefits  researchers,  there  is  a  danger  that  differing  choices  of 
extensions  will  make  users  distinguishable.  Experiments  should  be  run  on  a  separate 
network.) 

Simple  design:  The  protocol’s  design  and  security  parameters  must  be  well-understood. 
Additional  features  impose  implementation  and  complexity  costs;  adding  unproven 
techniques  to  the  design  threatens  deployability,  readability,  and  ease  of  security  anal¬ 
ysis.  Tor  aims  to  deploy  a  simple  and  stable  system  that  integrates  the  best  accepted 
approaches  to  protecting  anonymity. 

Non-goals 

In  favoring  simple,  deployable  designs,  we  have  explicitly  deferred  several  possible 
goals,  either  because  they  are  solved  elsewhere,  or  because  they  are  not  yet  solved. 

Not  peer-to-peer:  Tarzan  and  MorphMix  aim  to  scale  to  completely  decentralized 
peer-to-peer  environments  with  thousands  of  short-lived  servers,  many  of  which  may 
be  controlled  by  an  adversary.  This  approach  is  appealing,  but  still  has  many  open 
problems,  such  as  greater  effects  of  Sybil  attacks  and  of  greater  network  dynamics 
[12,  17]. 

Not  secure  against  end-to-end  attacks:  We  do  not  claim  that  Tor  provides  a 
definitive  solution  to  end-to-end  attacks,  such  as  correlating  the  timing  of  connections 
opening  or  correlating  when  users  are  on  the  system  with  when  certain  traffic  is  ob¬ 
served  (also  known  as  intersection  attacks).  Some  approaches  may  help,  for  example, 
accessing  the  network  only  through  your  own  onion  router;  see  [10]  for  more  discus¬ 
sion. 

No  protocol  normalization:  Tor  does  not  provide  protocol  normalization  like 
Privoxy  [15]  or  the  Anonymizer  [2].  In  other  words.  Tor  anonymizes  the  channel, 
but  not  the  data  or  applications  that  pass  over  it.  This  means  that  Tor  in  itself  will  not 
hide,  for  example,  a  web  surfer  from  being  identified  by  the  data  or  application  proto¬ 
col  information  observed  at  a  visited  web  site.  If  anonymization  from  the  responder  is 
desired  for  complex  and  variable  protocols  like  HTTP,  Tor  must  be  layered  with  a  fil¬ 
tering  proxy  such  as  Privoxy  to  hide  differences  between  clients,  and  expunge  protocol 
features  that  leak  identity.  Note  that  by  this  separation  Tor  can  also  provide  services 
that  are  anonymous  to  the  network  yet  authenticated  to  the  responder,  like  SSH.  So, 
for  example,  road  warriors  can  make  authenticated  connections  to  their  home  systems 
without  revealing  this  to  anyone  including  the  local  network  access  point.  Similarly, 

Tor  does  not  currently  integrate  tunneling  for  non-stream-based  protocols  like  UDP; 
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this  too  must  be  provided  by  an  external  service. 

Not  steganographic:  Tor  does  not  try  to  conceal  who  is  connected  to  the  network 
from  someone  in  a  position  to  observe  that  connection. 

2.1  Threat  Model 

A  global  passive  adversary  is  the  most  commonly  assumed  threat  when  analyzing  the¬ 
oretical  anonymity  designs.  But  like  all  practical  low-latency  systems.  Tor  does  not 
protect  against  such  a  strong  adversary.  Instead,  we  assume  an  adversary  who  can 
observe  some  fraction  of  network  traffic;  who  can  generate,  modify,  delete,  or  delay 
traffic;  who  can  operate  onion  routers  of  its  own;  and  who  can  compromise  some  frac¬ 
tion  of  the  onion  routers. 

In  low-latency  anonymity  systems  that  use  layered  encryption,  the  adversary’s  typ¬ 
ical  goal  is  to  observe  both  the  initiator  and  the  responder.  By  observing  both  ends, 
passive  attackers  can  confirm  a  suspicion  that  Alice  is  talking  to  Bob  if  the  timing  and 
volume  patterns  of  the  traffic  on  the  connection  are  distinct  enough;  active  attackers 
can  induce  timing  signatures  on  the  traffic  to  force  distinct  patterns.  Rather  than  fo¬ 
cusing  on  these  traffic  confirmation  attacks,  we  aim  to  prevent  traffic  analysis  attacks, 
where  the  adversary  uses  traffic  patterns  to  learn  which  points  in  the  network  he  should 
attack. 

Our  adversary  might  try  to  link  an  initiator  Alice  with  her  communication  part¬ 
ners,  or  try  to  build  a  profile  of  Alice’s  behavior.  He  might  mount  passive  attacks  by 
observing  the  network  edges  and  correlating  traffic  entering  and  leaving  the  network — 
by  relationships  in  packet  timing,  volume,  or  externally  visible  user-selected  options. 
The  adversary  can  also  mount  active  attacks  by  compromising  routers  or  keys;  by  re¬ 
playing  traffic;  by  selectively  denying  service  to  trustworthy  routers  to  move  users 
to  compromised  routers,  or  denying  service  to  users  to  see  if  traffic  elsewhere  in  the 
network  stops;  or  by  introducing  patterns  into  traffic  that  can  later  be  detected.  The 
adversary  might  subvert  the  directory  servers  to  give  users  differing  views  of  network 
state.  Additionally,  he  can  try  to  decrease  the  network’s  reliability  by  attacking  nodes 
or  by  performing  antisocial  activities  from  reliable  servers  and  trying  to  get  them  taken 
down;  making  the  network  unreliable  flushes  users  to  other  less  anonymous  systems, 
where  they  may  be  easier  to  attack. 

3  Highlights  of  the  Tor  Design 

The  Tor  network  is  an  overlay  network;  each  onion  router  (OR)  runs  as  a  normal 
user-level  process  without  any  special  privileges.  Each  onion  router  maintains  a  long¬ 
term  TLS  [8]  connection  to  every  other  onion  router.  Using  TLS  conceals  the  data 
on  the  connection  with  perfect  forward  secrecy  (see  below),  and  prevents  an  attacker 
from  modifying  data  on  the  wire  or  impersonating  an  OR.  Each  user  runs  local  soft¬ 
ware  called  an  onion  proxy  (OP)  to  fetch  directories,  establish  circuits  across  the  net¬ 
work,  and  handle  connections  from  user  applications.  These  onion  proxies  accept  TCP 
streams  and  multiplex  them  across  the  circuits.  The  onion  router  on  the  other  side  of 
the  circuit  connects  to  the  destinations  of  the  TCP  streams  and  relays  data. 


RTO-MP-IST-041 


18-5 


Resisting  Traffic  Analysis  on  Unclassified  Networks 


ORGANIZATION 


Traffic  passes  along  these  connections  in  fixed-size  cells.  Each  cell  is  512  bytes, 
and  consists  of  a  header  and  a  payload.  The  header  includes  a  circuit  identifier  (circID) 
that  specifies  which  circuit  the  cell  refers  to  (many  circuits  can  be  multiplexed  over 
each  TLS  connection),  and  a  command  to  describe  what  to  do  with  the  cell’s  payload. 
(Circuit  identifiers  are  connection-specific:  each  single  circuit  has  a  different  circID  on 
each  OP/OR  or  OR/OR  connection  it  traverses.)  Based  on  their  command,  cells  are 
either  control  cells,  which  are  always  interpreted  by  the  node  that  receives  them,  or 
relay  cells,  which  carry  end-to-end  stream  data. 

Relay  cells  have  an  additional  header  (the  relay  header)  after  the  cell  header,  con¬ 
taining  a  stream  identifier  (many  streams  can  be  multiplexed  over  a  circuit);  an  end- 
to-end  checksum  for  integrity  checking;  the  length  of  the  relay  payload;  and  a  relay 
command.  The  entire  contents  of  the  relay  header  and  the  relay  cell  payload  are  en¬ 
crypted  or  decrypted  together  as  the  relay  cell  moves  along  the  circuit,  using  the  128-bit 
AES  cipher  in  counter  mode  to  generate  a  cipher  stream. 

In  Tor,  just  as  each  connection  can  be  shared  by  many  circuits,  each  circuit  can 
be  shared  by  many  application-level  TCP  streams.  To  avoid  delays,  users  construct 
circuits  preemptively.  To  limit  linkability  among  their  streams,  users’  OPs  build  a 
new  circuit  periodically  if  the  previous  one  has  been  used,  and  expire  old  used  circuits 
that  no  longer  have  any  open  streams.  OPs  consider  making  a  new  circuit  once  a 
minute:  thus  even  heavy  users  spend  negligible  time  building  circuits,  but  a  limited 
number  of  requests  can  be  linked  to  each  other  through  a  given  exit  node.  Also,  because 
circuits  are  built  in  the  background,  OPs  can  recover  from  failed  circuit  creation  without 
delaying  streams  (which  would  harm  user  experience). 

The  full  Tor  design  paper  [10]  describes  the  Onion  Routing  protocol  in  detail;  we 
highlight  a  few  of  its  properties  here: 

•  Perfect  forward  secrecy:  Onion  Routing  was  originally  vulnerable  to  a  single 
hostile  node  recording  traffic  and  later  compromising  successive  nodes  in  the  cir¬ 
cuit  and  forcing  them  to  decrypt  it.  Rather  than  using  a  single  multiply  encrypted 
data  structure  (an  onion )  to  lay  each  circuit.  Tor  now  uses  an  incremental  or  tele¬ 
scoping  path-building  design,  where  the  initiator  negotiates  session  keys  with 
each  successive  hop  in  the  circuit.  Once  these  keys  are  deleted,  subsequently 
compromised  nodes  cannot  decrypt  old  traffic.  As  a  side  benefit,  onion  replay 
detection  is  no  longer  necessary,  and  the  process  of  building  circuits  is  more  re¬ 
liable,  since  the  initiator  knows  when  a  hop  fails  and  can  then  try  extending  to  a 
new  node. 

•  Leaky-pipe  circuit  topology:  Through  in-band  signaling  within  the  circuit.  Tor 
initiators  can  direct  traffic  to  nodes  partway  down  the  circuit.  This  novel  ap¬ 
proach  allows  traffic  to  exit  the  circuit  from  the  middle — possibly  frustrating 
traffic  shape  and  volume  attacks  based  on  observing  the  end  of  the  circuit.  (It 
also  allows  for  long-range  padding  if  future  research  shows  this  to  be  worth¬ 
while.) 

•  End-to-end  integrity  checking:  The  original  Onion  Routing  design  did  no  in¬ 
tegrity  checking  on  data.  Any  node  on  the  circuit  could  change  the  contents 
of  data  cells  as  they  passed  by — for  example,  to  alter  a  connection  request  so 
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it  would  connect  to  a  different  Webserver,  or  to  ‘tag’  encrypted  traffic  and  look 
for  corresponding  corrupted  traffic  at  the  network  edges  [7].  Tor  hampers  these 
attacks  by  checking  data  integrity  before  it  leaves  the  network. 

•  Improved  robustness  to  failed  nodes:  A  failed  node  in  the  old  design  meant 
that  circuit  building  failed,  but  thanks  to  Tor’s  step-by-step  circuit  building,  users 
notice  failed  nodes  while  building  circuits  and  route  around  them.  Additionally, 
liveness  information  from  directories  allows  users  to  avoid  unreliable  nodes  in 
the  first  place. 

•  Congestion  control:  Even  with  bandwidth  rate  limiting,  we  still  need  to  worry 
about  congestion,  either  accidental  or  intentional.  If  enough  users  choose  the 
same  OR-to-OR  connection  for  their  circuits,  that  connection  can  become  satu¬ 
rated.  For  example,  an  attacker  could  send  a  large  file  through  the  Tor  network  to 
a  Webserver  he  runs,  and  then  refuse  to  read  any  of  the  bytes  at  the  Webserver  end 
of  the  circuit.  Without  some  congestion  control  mechanism,  these  bottlenecks 
can  propagate  back  through  the  entire  network.  We  don’t  need  to  reimplement 
full  TCP  windows  (with  sequence  numbers,  the  ability  to  drop  cells  when  we’re 
full  and  retransmit  later,  and  so  on),  because  TCP  already  guarantees  in-order 
delivery  of  each  cell.  Tor  provides  both  circuit  and  stream  level  throttling. 


4  Other  design  decisions 

4.1  Resource  management  and  denial-of-service 

Providing  Tor  as  a  public  service  creates  many  opportunities  for  denial-of-service  at¬ 
tacks  against  the  network.  While  flow  control  and  rate  limiting  prevent  users  from 
consuming  more  bandwidth  than  routers  are  willing  to  provide,  opportunities  remain 
for  users  to  consume  more  network  resources  than  their  fair  share,  or  to  render  the 
network  unusable  for  others.  We  discuss  some  of  these  in  [10]. 

4.2  Exit  policies  and  abuse 

Exit  abuse  is  a  serious  barrier  to  wide-scale  Tor  deployment.  Anonymity  presents 
would-be  vandals  and  abusers  with  an  opportunity  to  hide  the  origins  of  their  activ¬ 
ities.  Attackers  can  harm  the  Tor  network  by  implicating  exit  servers  for  their  abuse. 
Also,  applications  that  commonly  use  IP-based  authentication  (such  as  institutional 
mail  or  webservers)  can  be  fooled  by  the  fact  that  anonymous  connections  appear  to 
originate  at  the  exit  OR. 

We  stress  that  Tor  does  not  enable  any  new  class  of  abuse.  Spammers  and  other 
attackers  already  have  access  to  thousands  of  misconfigured  systems  worldwide,  and 
the  Tor  network  is  far  from  the  easiest  way  to  launch  antisocial  or  illegal  attacks.  But 
because  the  onion  routers  can  easily  be  mistaken  for  the  originators  of  the  abuse,  and 
the  volunteers  who  run  them  may  not  want  to  deal  with  the  hassle  of  repeatedly  ex¬ 
plaining  anonymity  networks,  we  must  block  or  limit  the  abuse  that  travels  through  the 
Tor  network. 


RTO-MP-IST-041 


18-7 


Resisting  Traffic  Analysis  on  Unclassified  Networks 


ORGANIZATION 


To  mitigate  abuse  issues,  in  Tor,  each  onion  router’s  exit  policy  describes  to  which 
external  addresses  and  ports  the  router  will  connect.  This  is  described  further  in  [10]. 

Finally,  we  note  that  exit  abuse  must  not  be  dismissed  as  a  peripheral  issue:  when  a 
system’s  public  image  suffers,  it  can  reduce  the  number  and  diversity  of  that  system’s 
users,  and  thereby  reduce  the  anonymity  of  the  system  itself.  Like  usability,  public 
perception  is  a  security  parameter.  Sadly,  preventing  abuse  of  open  exit  nodes  is  an 
unsolved  problem,  and  will  probably  remain  an  arms  race  for  the  foreseeable  future. 
The  abuse  problems  faced  by  Princeton’s  CoDeeN  project  [14]  give  us  a  glimpse  of 
likely  issues. 

4.3  Directory  Servers 

First-generation  Onion  Routing  designs  [4,  16]  used  in-band  network  status  updates: 
each  router  flooded  a  signed  statement  to  its  neighbors,  which  propagated  it  onward. 
But  anonymizing  networks  have  different  security  goals  than  typical  link-state  routing 
protocols.  For  example,  delays  (accidental  or  intentional)  that  can  cause  different  parts 
of  the  network  to  have  different  views  of  link-state  and  topology  are  not  only  incon¬ 
venient:  they  give  attackers  an  opportunity  to  exploit  differences  in  client  knowledge, 
by  observing  induced  differences  in  client  behavior.  We  also  worry  about  attacks  to 
deceive  a  client  about  the  router  membership  list,  topology,  or  current  network  state. 
Such  partitioning  attacks  on  client  knowledge  help  an  adversary  to  efficiently  deploy 
resources  against  a  target  [7], 

Tor  uses  a  small  group  of  redundant,  well-known  onion  routers  to  track  changes  in 
network  topology  and  node  state,  including  keys  and  exit  policies.  Each  such  directory 
server  acts  as  an  HTTP  server,  so  participants  can  fetch  current  network  state  and 
router  lists,  and  so  other  ORs  can  upload  state  information.  Onion  routers  periodically 
publish  signed  statements  of  their  state  to  each  directory  server.  The  directory  servers 
combine  this  state  information  with  their  own  views  of  network  liveness,  and  generate 
a  signed  description  (a  directory )  of  the  entire  network  state.  Client  software  is  pre- 
loaded  with  a  list  of  the  directory  servers  and  their  keys,  to  bootstrap  each  client’s  view 
of  the  network.  More  details  are  provided  in  [10]. 

Using  directory  servers  is  simpler  and  more  flexible  than  flooding.  Flooding  is 
expensive,  and  complicates  the  analysis  when  we  start  experimenting  with  non-clique 
network  topologies.  Signed  directories  can  be  cached  by  other  onion  routers,  so  direc¬ 
tory  servers  are  not  a  performance  bottleneck  when  we  have  many  users,  and  do  not 
aid  traffic  analysis  by  forcing  clients  to  periodically  announce  their  existence  to  any 
central  point. 


5  Rendezvous  points  and  hidden  services 

Rendezvous  points  are  a  building  block  for  location-hidden  sendees  (also  known  as 
responder  anonymity)  in  the  Tor  network.  Location-hidden  services  allow  Bob  to  offer 
a  TCP  service,  such  as  a  Webserver,  without  revealing  its  IP  address.  This  type  of 
anonymity  protects  against  distributed  DoS  attacks:  attackers  are  forced  to  attack  the 
onion  routing  network  as  a  whole  rather  than  just  Bob’s  IP  address. 
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Our  design  for  location-hidden  servers  has  the  following  goals.  Access-controlled: 
Bob  needs  a  way  to  filter  incoming  requests,  so  an  attacker  cannot  flood  Bob  simply  by 
making  many  connections  to  him.  Robust:  Bob  should  be  able  to  maintain  a  long-term 
pseudonymous  identity  even  in  the  presence  of  router  failure.  Bob’s  service  must  not 
be  tied  to  a  single  OR,  and  Bob  must  be  able  to  tie  his  service  to  new  ORs.  Smear- 
resistant:  A  social  attacker  who  offers  an  illegal  or  disreputable  location-hidden  ser¬ 
vice  should  not  be  able  to  “frame”  a  rendezvous  router  by  making  observers  believe 
the  router  created  that  service.  Application-transparent:  Although  we  require  users 
to  run  special  software  to  access  location-hidden  servers,  we  must  not  require  them  to 
modify  their  applications. 

We  provide  location-hiding  for  Bob  by  allowing  him  to  advertise  several  onion 
routers  (his  introduction  points )  as  contact  points.  He  may  do  this  on  any  robust  effi¬ 
cient  key-value  lookup  system  with  authenticated  updates,  such  as  a  distributed  hash 
table  (DHT)  like  CFS  [6]1  Alice,  the  client,  chooses  an  OR  as  her  rendezvous  point. 
She  connects  to  one  of  Bob’s  introduction  points,  informs  him  of  her  rendezvous  point, 
and  then  waits  for  him  to  connect  to  the  rendezvous  point.  This  extra  level  of  indirec¬ 
tion  helps  Bob’s  introduction  points  avoid  problems  associated  with  serving  unpopular 
files  directly  (for  example,  if  Bob  serves  material  that  the  introduction  point’s  commu¬ 
nity  finds  objectionable,  or  if  Bob’s  service  tends  to  get  attacked  by  network  vandals). 
The  extra  level  of  indirection  also  allows  Bob  to  respond  to  some  requests  and  ignore 
others. 

5.1  Integration  with  user  applications 

Bob  configures  his  onion  proxy  to  know  the  local  IP  address  and  port  of  his  service, 
a  strategy  for  authorizing  clients,  and  a  public  key.  Bob  publishes  the  public  key,  an 
expiration  time  (“not  valid  after”),  and  the  current  introduction  points  for  his  service 
into  the  DHT,  indexed  by  the  hash  of  the  public  key.  Bob’s  Webserver  is  unmodified, 
and  doesn’t  even  know  that  it’s  hidden  behind  the  Tor  network. 

Alice’s  applications  also  work  unchanged — her  client  interface  remains  a  SOCKS 
proxy.  We  encode  all  of  the  necessary  information  into  the  fully  qualified  domain  name 
Alice  uses  when  establishing  her  connection.  Location-hidden  services  use  a  virtual  top 
level  domain  called  .  onion:  thus  hostnames  take  the  form  x .  y .  onion  where  x  is 
the  authorization  cookie,  and  y  encodes  the  hash  of  the  public  key.  Alice’s  onion  proxy 
examines  addresses;  if  they’re  destined  for  a  hidden  server,  it  decodes  the  key  and  starts 
the  rendezvous  as  described  above. 


6  Future  Directions 

Tor  brings  together  many  innovations  into  a  unified  deployable  system.  The  next  im¬ 
mediate  steps  include: 

Scalability:  Tor’s  emphasis  on  deployability  and  design  simplicity  has  led  us  to 
adopt  a  clique  topology,  semi-centralized  directories,  and  a  full-network- visibility  model 


1  Rather  than  rely  on  an  external  infrastructure,  the  Onion  Routing  network  can  run  the  DHT  itself.  At 
first,  we  can  run  a  simple  lookup  system  on  the  directory  servers. 
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for  client  knowledge.  These  properties  will  not  scale  past  a  few  hundred  servers.  The 
Tor  design  paper  [10]  describes  some  promising  approaches,  but  more  deployment  ex¬ 
perience  will  be  helpful  in  learning  the  relative  importance  of  these  bottlenecks. 

Bandwidth  classes:  This  paper  assumes  that  all  ORs  have  good  bandwidth  and 
latency.  We  should  instead  adopt  the  MorphMix  model,  where  nodes  advertise  their 
bandwidth  level  (DSL,  Tl,  T3),  and  Alice  avoids  bottlenecks  by  choosing  nodes  that 
match  or  exceed  her  bandwidth.  In  this  way  DSL  users  can  usefully  join  the  Tor  net¬ 
work. 

Incentives:  Volunteers  who  run  nodes  are  rewarded  with  potentially  better  anonymity, 
and  those  who  value  the  notoriety  can  be  rewarded  with  publicity  [1],  More  nodes 
means  increased  scalability,  and  more  users  can  mean  more  anonymity.  We  need  to 
continue  examining  the  incentive  structures  for  participating  in  Tor. 

Padding  Cover  traffic:  Currently  Tor  omits  padding  for  cover  traffic — its  costs  in 
performance  and  bandwidth  are  clear  but  its  security  benefits  are  not  well  understood. 
We  must  pursue  more  research  on  link-level  cover  traffic  and  long-range  cover  traffic 
to  determine  whether  some  simple  padding  method  offers  provable  protection  against 
our  chosen  adversary. 

Caching  at  exit  nodes:  Perhaps  each  exit  node  should  run  a  caching  web  proxy,  to 
improve  anonymity  for  cached  pages  (Alice’s  request  never  leaves  the  Tor  network),  to 
improve  speed,  and  to  reduce  bandwidth  cost.  On  the  other  hand,  forward  security  is 
weakened  because  caches  constitute  a  record  of  retrieved  files.  We  must  find  the  right 
balance  between  usability  and  security. 

Better  directory  distribution:  Clients  currently  download  a  description  of  the  entire 
network  every  15  minutes.  As  the  state  grows  larger  and  clients  more  numerous,  we 
may  need  a  solution  in  which  clients  receive  incremental  updates  to  directory  state. 
More  generally,  we  must  find  more  scalable  yet  practical  ways  to  distribute  up-to-date 
snapshots  of  network  status  without  introducing  new  attacks. 

Implement  location-hidden  services:  The  design  in  Section  5  has  not  yet  been  im¬ 
plemented.  While  doing  so  we  are  likely  to  encounter  additional  issues  that  must  be 
resolved,  both  in  terms  of  usability  and  anonymity. 

Further  specification  review:  Although  we  have  a  public  byte-level  specification 
for  the  Tor  protocols,  it  needs  extensive  external  review.  We  hope  that  as  Tor  is  more 
widely  deployed,  more  people  will  examine  its  specification. 

Multisystem  interoperability:  We  are  currently  working  with  the  designer  of  Mor¬ 
phMix  to  unify  the  specification  and  implementation  of  the  common  elements  of  our 
two  systems.  So  far,  this  seems  to  be  relatively  straightforward.  Interoperability  will 
allow  testing  and  direct  comparison  of  the  two  designs  for  trust  and  scalability. 

Wider-scale  deployment:  The  original  goal  of  Tor  was  to  gain  experience  in  de¬ 
ploying  an  anonymizing  overlay  network,  and  learn  from  having  actual  users.  As  of 
writing  there  is  a  distributed  network  of  roughly  a  dozen  nodes.  We  are  now  at  a  point 
in  design  and  development  where  we  can  start  deploying  a  wider  network.  Once  we 
have  many  actual  users,  we  will  doubtlessly  be  better  able  to  evaluate  some  of  our  de¬ 
sign  decisions,  including  our  robustness/latency  tradeoffs,  our  performance  tradeoffs 
(including  cell  size),  our  abuse-prevention  mechanisms,  and  our  overall  usability. 
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Talk  Outline 


•  Motivation:  Why  traffic  analysis  resistant  communication? 

What  can  Defense  do  with  anonymity? 

•  Note:  Anonymous  Comm.  =  Traffic  Analysis  Resistant  Comm. 

•  Properties  and  types  of  anonymity 

•  Mixes  and  Proxies:  Anonymity  building  blocks 

•  Onion  Routing:  Lower  latency,  Higher  Security 

•  Features  of  Tor:  2nd  Generation  Onion  Routing 

•  Summary  and  Future  Work 
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Public  Networks  are  Vulnerable  to 

Traffic  Analysis 

In  public  networks  (Internet)  /  large  closed  networks: 

•  Packet  (message)  headers  identify  recipients 

•  Packet  routes  can  be  tracked 


Encryption  does  not  hide  routing  information. 


BMVg/DoD/MoD/&c  Needs  Anonymity? 

Yes,  for... 
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•  Open  source  intelligence  gathering 

[3D  Hiding  individual  analysts  is  not  enough 

[3D That  a  query  was  from  a  govt,  source  may  be  sensitive 

•  Defense  in  depth  on  open  and  classified  networks 

[3DNetworks  with  only  cleared  users  (but  a  million  of  them) 

•  Dynamic  and  semitrusted  international  coalitions 

[3DNetwork  can  be  shared  without  revealing  existence  or  amount 
of  communication  between  all  parties 
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Defense  Needs  Anonymity? 

Yes,  for... 


•  Networks  partially  under  known  hostile  control 

[3D To  block  comm,  enemy  must  take  down  whole  network 

•  Politically  Sensitive  negotiations 

•  Road  Warriors 

•  Protecting  procurement  patterns 

•  Homeland  Security  Information  from  municipalities, 
industry,... 

•  Anonymous  tips 
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DoD/MoD  Needs  Anonymity? 

Yes,  for... 


•  Virtual  Hidden  Networks 

[3D  Traditional  VPNs  are  not  private 

[3D  Anyone  can  see  the  network 

[3D  Often  adversary  can  see  amount  of  communication 

Onion  Routing  leverages  sharing,  reduce  countermeasure  cost 

•  Location  Hidden  Services 

[3D  Service  accessible  from  anywhere 
[3D  Resist  Distributed  DoS 
[3D  Resist  physical  attack 
[3D  Minimize  redundancy,  Reduce  costs 
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Anonymity  Loves  Company 


•  You  can't  be  anonymous  by  yourself 
[3D Can  have  confidentiality  by  yourself 


•  A  network  that  protects  only  DoD  network  users  won't  hide  that 
connections  from  that  network  are  from  Defense  Dept. 

•  Need  to  share  creates  interesting  incentive  issues  for  network 
users  and  servers 
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Others  Who  Need  Anonymity 


•  Socially  sensitive  communicants: 

[3D Disease  or  crime  victim  chat  rooms 

•  Law  Enforcement: 

[3D  Anonymous  tips  or  crime  reporting 

[3D  Surveillance  and  honeypots  (sting  operations) 

•  Corporations: 

[3D  Hiding  collaborations  of  sensitive  business  units  or  partners 
[3D  Hide  procurement  suppliers  or  patterns 

•  Censorship  resistant  publishers 

•  Whistleblowers 
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Anonymous  From  Whom? 

Adversary  Model 

•  Recipient  of  your  message 

•  Sender  of  your  message 

Need  Channel  and  Data  Anonymity 

•  Observer  of  network  from  outside 

•  Network  Infrastructure  (Insider) 

Need  Channel  Anonymity 


•  Note:  Anonymous  authenticated  communication  makes  perfect 
sense 

•  Communicant  identification  should  be  in  the  basic  channel  not 
of  the  channel 
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Focus  of  this  work  is  anonymity  of  the 

communication  pipe, 
not  what  goes  through  it 
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How  Do  You  Get  Anonymity? 

•  Many  technical  approaches 

•  Overview  of  two  extensively  used  approaches 

[^DMixes 

[^Proxies 


What  does  a  mix  network  do? 


message  1 


►  message  2 


message  3 


message  4 


Randomly  permutes  and  decrypts  inputs 
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What  does  a  mix  network  do? 


message  2 


Key  property:  Adversary  can't  tell  which  ciphertext 
corresponds  to  a  given  message 
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A  look  under  the  hood 


Basic  Mix  (Chaum  ‘81) 
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Server  1 


Server  2 


Server  3 


Encryption  of  Message 


PKi 


PK- 


Ciphertext  =  EPK1[EpK2[EpK3[message]]] 


Basic  Chaum-type  Mix 


decrypt 

and 

permute 


decrypt 

and 

permute 


mzi  d*»r 

permute 


One  honest  server  preserves  privacy 
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What  if  you  need  quick  interaction? 


•  Web  browsing,  Remote  login,  Chat,  etc. 


•  Mixnets  introduced  for  email  and  other  high  latency  apps 


•  Each  layer  of  message  requires 
expensive  public-key  crypto 
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•  Appropriate  for  Web  connections,  etc.: 

SSL,  TLS,  SSH  (lower  cost  symmetric  encryption) 

•  Examples:  The  Anonymizer 

•  Advantages:  Simple,  Focuses  lots  of  traffic  for  more  anonymity 

•  Main  Disadvantage:  Single  point  of  failure,  compromise,  attack 
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Onion  Routing 

Traffic  Analysis  Resistant  Infrastructure 


•  Main  Idea:  Combine  Advantages  of  mixes  and  proxies 

•  Use  (expensive)  public-key  crypto  to  establish  circuits 
Use  (cheaper)  symmetric-key  crypto  to  move  data 

[3DLike  SSL/TLS  based  proxies 

•  Use  distributed  infrastructure  like  mixes 

•  Related  Work: 

[3D Crowds,  JAP  Webmixes,  Freedom  Network 

[3D  Ask  me  at  the  end  if  there's  time 

[3D  (and  Onion  Routing  is  the  best  anyway) 


Network  Structure 


Onion  routers  form  an  overlay  network 
[3D  Clique  topology  (for  now) 

[3D  Longstanding  TLS  encrypted  connections  (thick  pipes) 


Proxy  interfaces  between  client  machine  and  onion  routing 
overlay  network 


Client 

Initiator 


Responder 


Internet 


Tor 
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Tor 


The  Onion  Routing 
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Tor 


Tor's  Onion  Routing 
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Circuit  Setup  (Create) 

Client  chooses  first  node,  establishes  session  key  over  TLS  connection 


Client 

Initiator 


Onion  Router 


TLS  connection 
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Circuit  Setup  (Create) 

Client  chooses  first  node,  establishes  session  key  over  TLS  connection 


Client 

Initiator 


Onion  Router 


18-28 


Circuit  Setup  (Extend) 

Client  chooses  first  node,  establishes  session  key  over  TLS  connection 


Client 

Initiator 


Circuit  Setup  (Begin)and  Data  Flow 


Slight  simplification  of  actual  protocol 


■ 


A 


OR2 


18-30 


Where  do  I  go  to  connect  to  the  network? 


•  Directory  Servers 

[^Maintain  list  of  which  onion  routers  are  up,  their  locations,  current 
keys,  exit  policies,  etc. 

[3D Control  which  nodes  can  join  network 

Important  to  guard  against  pseudospoofmg  attack  and  related 
problems 


18-31 


Some  Tor  Properties/Improvements 


•  Simple  modular  design,  Restricted  ambitions 
[3DCirca  20K  lines  of  C  code 

[3DEven  servers  mn  in  user  space,  no  need  to  be  root 
[3D  Just  anonymize  the  pipe 

Can  use  privoxy  as  front  end  if  desired  to  anonymize  data 

[3DSOCKS  compliant  TCP:  includes  Web,  remote  login,  mail,  chat, 
more 

No  need  to  build  proxies  for  every  application 

[3DFlexible  exit  policies,  each  node  chooses  what 
applications/destinations  can  emerge  from  it 
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Some  Tor  Properties/Improvements 

•  Lots  of  supported  platforms: 

Linux,  BSD,  MacOS,  Solaris,  Windows 

•  Many  TCP  streams  (application  connections)  share  one 
anonymous  circuit 

[3DLess  public-key  encryption  overhead  than  prior  design 
[3D Reduced  anonymity  danger  from  opening  many  circuits 
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OR  Generations  0  and  1  Circuit  Setup 


The  initial  proxy  knows  the  Onion  Routing  network  topology, 
selects  a  route,  and  generates  the  onion 

Each  layer  of  the  onion  identifies  the  next  hop  in  the  route 
and  contains  the  cryptographic  keys  to  be  used  at  that  node. 
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Numbers  and  Performance 


•  Prototype  ran  for  two  years 

[3D4  nodes  running  at  a  single  location 

[3D  During  final  months  processed  over  5 OK  Web  connections/day  from 
a  total  of  60K  IP  addresses  worldwide 

•  Current  2nd  Gen  design  running  since  October  2003 

[3Dc.  20  nodes  scattered  through  US  and  Europe 
[3D Hundreds  of  users 
[3D  Average  node  processes  .5  GB  /  week 
[3DNetwork  has  never  been  down 
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Latency  Tests 

•  4  node  test  network  on  single  heavily  loaded  1  Ghz  Athlon 

[^Download  60MB  file  (108  times  over  54  hours) 

[3D 3 00  sec  /download  vs.  210  sec/download  without  OR 

•  Production  network  test 

3DDownload  cnn.com  55KB 

[3D  Varied  from  .6  sec  to  2.7  sec  through  Tor  vs.  .3  sec  direct 
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Rendezvous  Point  Protocol  Overview 


1.  Bob  opens  OR  connections  to  “introduction  points” 

2.  Bob  makes  these  known  to  Alice  (anonymously  or  not) 

3.  Alice  creates  connection  to  “rendezvous  point” 

4.  Alice  connects  to  Bob  via  introduction  point,  gives  rendezvous 
location  possible  authorization  to  Bob 

5.  Bob  decides  if  he  will  contact  Alice 

6.  If  so,  Bob  anonymously  routes  to  rendezvous  point 

7.  Rendezvous  point  mates  connection 
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Location  Hidden  Servers 

Alice  can  connect  to  Bob’s  server  without  knowing  where  it  is  or 
possibly  who  he  is  via  rendezvous  points 

Can  provide  servers  that 
[3DResist  censorship 

[3D Require  minimal  redundancy  for  resilience  in  denial  of  service 
(DoS)  attack 

[3D  Can  survive  to  provide  selected  service  even  during  full  blown 
distributed  DoS  attack 

[3D  Resistant  to  physical  attack  (you  can’t  find  them) 
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Future  Work 


•  Design  and  build  distributed  directory  management 

•  Implement  location  hidden  servers 

•  Integrate  with  other  designs 

[3D  Already  made  P2P  Morphmix  design  share  most  of  codebase 

•  Restricted-route  (non-clique)  topology 

[3D  To  scale  beyond  hundred  of  nodes  and  lOKs  of  users 
(We  should  have  such  problems) 

•  Make  it  all  work  better 

•  Certification  and  Accreditation:  Common  Criteria 

•  More  theoretical  work 

fit  Midlatency  synchronous  batch  netmixes?!? 


Get  the  Code,  Run  a  Node! 

(or  just  surf  the  web  anonymously) 
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•  Original  Onion  Routing  design  is  patented 

[5D2001  Edison  Patent  Award 

•  Current  system  code  freely  available  (mod.  BSD  license) 

•  Visit  official  site  http://www.onion-router.net 

•  Visit  http://freehaven.net/tor/  to  download  design  paper,  system 
spec,  code,  see  the  list  of  current  nodes,  etc. 


18-40 


J’ai  fini. 


Questions? 
Suis-je  fini? 


http :  //  www .  onion-router .  net 


18-41 


Still  More  Advantages 


Thick  pipe  bandwidth  rate  limiting 
[3D  Limits  how  much  one  OR  can  send  to  a  neighbor 
[3D  Token  bucket  approach  limits  average  but  permits  burstiness 
Circuit  and  stream  level  throttling 
[3D  Controls  congestion 

[3D Mitigates  denial  of  service  that  a  single  circuit  can  do 
Stream  integrity  checks 
[3D  Onion  Routing  uses  stream  ciphers 
[3D  Checks  prevent,  e.g.,  reasonable  guess  attack 
XOR  out  of  ’dir  ’  and  XOR  in  'rm  *’ 
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More  Tor  Advantages 


•  No  need  to  keep  track  of  onions  to  prevent  replay 

[3D  There  are  no  onions  anymore 

[3D  Even  a  replayed  create  cell  will  result  in  a  new  session  key  at  an 
honest  onion  router 

•  Perfect  Forward  Secrecy 

[3D  Storing  all  traffic  sent  to  a  node  and  later  breaking  its  public  key  will 
not  reveal  encrypted  content 

•  Can  adapt  to  network  dynamics  better 

[3D  Down  exit  node  or  unusable  exit  policy  does  not  require  building 
whole  new  circuit 


Circuit  Setup  (Begin)and  Data  Flow 


Slight  simplification  of  actual  protocol 


Web  server 


